Classic Load Balancer (CLB)

Overview#

The Classic Load Balancer (CLB) provides basic load balancing across multiple Amazon EC2 instances and operates at both the request and connection levels. It operates at layer 4 and layer 7. It supports the following protocols:

• TCP
• SSL
• HTTP
• HTTPS

Limitation

CLB does not support HTTP/2.

It integrates with Auto Scaling, CloudWatch, CloudTrail, and Route 53.

Load balancers can listen on the following ports:

• [EC2-VPC] 1-65535
• [EC2-Classic] 25, 80, 443, 465, 587, 1024-65535

CLBs do not have predefined IPv4 addresses but are resolved using a DNS name. However, they do support domain zone apex records, e.g., example.com. IPv4 and IPv6 are supported, but only IPv4 is supported within a VPC. It also provides SSL termination and processing.

Limitation

CLBs do not support Elastic IPs.

CLBs can work both internally and as Internet-facing. The diagram below shows how multiple CLBs can be used.

Sticky sessions#

• Cookie-based sticky sessions are supported.
• Session stickiness uses cookies and ensures a client is bound to an individual backend instance for the duration of the cookie lifetime.
• Cookies can be inserted by the application or by the load balancer when configured.
• After cookies expire, new requests will be routed by the load balancer normally, and a new cookie will be inserted and bind subsequent sessions to the same backend instance.
• With application-inserted cookies, if the backend instance becomes unhealthy, new requests will be routed by the load balancer normally, and a new cookie will be inserted and bind subsequent sessions to the same backend instance.
• With CLB-inserted cookies, if the backend instance becomes unhealthy, new requests will be routed by the load balancer normally, but the session will no longer be sticky.

The following slides show how sticky sessions work:

You must have multiple CLBs for multiple SSL certificates. Wildcard certificates are also supported.

Monitoring#

Instances monitored by CLB are reported as InService or OutofService.

Health checks

• Health checks can be configured for HTTP, TCP, HTTPS, and SSL.
• They can define timeout, interval, unhealthy threshold, and healthy threshold.
• Ping port specifies the port for the health check.
• Ping path specifies the path to check, e.g., /index.html.

For fault-tolerance, it is recommended to distribute registered instances across multiple AZs (ideally evenly).

Cross-zone load balancing#

• Cross-zone load balancing is enabled by default for CLB and ALB, but not for NLB (when created through the console).
• Cross-zone load balancing is NOT enabled by default if the CLB is created from the CLI or API.
• You can enable or disable cross-zone load balancing on the CLB and NLB at any time.
• For the ALB, cross-zone load balancing is always on and cannot be disabled.
• When cross-zone load balancing is enabled, each load balancer node distributes traffic across the registered targets in all enabled Availability Zones.
• When cross-zone load balancing is disabled, each load balancer node distributes traffic across the registered targets in its Availability Zone only.

Connection draining is enabled by default and provides a period of time for existing connections to close cleanly. When connection draining is in action, a CLB will be in the status InService: Instance deregistration currently in progress.

A CLB can take 1 to 7 minutes to detect an increase in load and scale. If you’re anticipating a fast increase in the load, you can contact AWS and instruct them to pre-warm (provision) additional CLB nodes.

The illustrations below show how cross-zone load balancing works.

Listeners#

A CLB listener is the process that checks for connection requests.

• You can configure the protocol/port on which your CLB listener listens.
• Front-end listeners check for traffic from clients to the CLB.
• Backend listeners are configured with the protocol/port to check for traffic from the CLB to the EC2 instances.
• Front-end and backend listeners can listen on ports 1-65535.
• Front-end and backend listeners must be at the same layer (e.g., layer 4 or layer 7).
• There is a 1:1 mapping between front-end and backend listeners.
• Up to 100 listeners can be configured.
• Supports L4 (TCP, SSL) and L7 (HTTP, HTTPS) listeners.

Proxy protocol#

Proxy protocol for TCP/SSL carries the source (client) IP/port information. The proxy protocol header helps you identify the IP address of a client when you have a load balancer that uses TCP for backend connections. Ensure that the client doesn’t go through a proxy, or there will be multiple proxy headers.

• With packet interception, the source IP/port will be from the ELB.
• You also need to ensure that the EC2 instance’s TCP stack can process the extra information.
• Proxy protocol only applies to L4.

X-forwarded-for for HTTP/HTTPS#

X-forwarded-for for HTTP/HTTPS carries the source IP/port information. To use an HTTPS listener, the CLB must have an X.509 SSL/TLS server certificate — this will allow the CLB to terminate the client’s secure session to the CLB.

• The session between the CLB and the EC2 instance can be re-encrypted.
• You can use a certificate generated by AWS Certificate Manager (ACM) or your own certificate.
• X-forwarded-for only applies to L7.
• If you don’t want interception/offloading, you can use TCP listeners with certificates on the EC2 instances (traffic is secured end-to-end).

To filter by source IP, use NACLs for proxy protocol (L4) / X-forwarded-for (L7) headers with the EC2 instance’s application performing the filtering.

Security#

• CLB supports a single X.509 certificate. Two-way authentication with client certificates is not supported on the CLB. For that, you would need to pass through the session using the proxy protocol and have an application that supports client-side certificates.
• When using end-to-end encryption, use TCP, not SSL/HTTPS on the CLB since SSL/HTTPS does not support session stickiness.
• AWS ACM certificates include an RSA public key. Ensure that you include a set of ciphers that support RSA in the security policy.

Update

The latest predefined security policy does not include support for SSLv3. When choosing a custom security policy, you can select the ciphers and protocols (only for CLB).

SSL Security Policy includes:

• Protocol Versions (SSL/TLS)
  • Supports TLS 1.0, 1.1, 1.2, SSL 3.0
• SSL Ciphers
  • Encryption algorithms
  • SSL can use different ciphers to encrypt data.
• Server Order Preference
  • When enabled, the first match in the cipher list with the Client list is used.
  • If disabled (default), the first match in the client cipher list with the CLB is used.